Service Functions rsrv() and wsrv()

Service Functions rsrv() and wsrv()

When a STREAMS driver defers message processing by setting the kernel function putq() address as the driver's put() function, the queue must also define a service function srv().

Because the srv() function for a given queue is addressed from the associated qinit structure, there is no requirement that the srv() function be a public name, and no requirement that it begin with the prefix string.

The prototype of a svr() function is as follows:

int
name(queue_t *q);

The srv() function for the write queue, which handles messages moving "downstream" from the user process toward the driver, is conventionally called the wsrv() function. The srv() function for the read queue, which handles messages moving "upstream" from the driver toward the user process, is conventionally called the rsrv() function.

An srv() function is called by the STREAMS monitor to deal with queued messages. It is called at a time chosen by the monitor, not necessarily related to any call to the put() function for the same queue. In a multiprocessor, only one instance of srv() is called per queue at any time. However, one or more instances of the put() function could execute concurrently with the srv() function--so any data that is used in common by put() and srv() must be protected with a lock (see "Waiting and Mutual Exclusion"). User-level code can also execute concurrently with a service function.

The service function is expected to dispose of all queued messages through one of the following actions:

Consuming and freeing the message.
Passing the message on to the following queue using putnext() (see the putnext(D3) reference page).
Replacing the message on the same queue using putbq() for processing later (see the putbq(D3) reference page).

The service function implements flow control (which the put() function cannot do). Before applying putnext(), the service function calls a flow control function such as canputnext() to find out if the following queue can accept a message. If the following queue cannot accept a message, the service function replaces the message with putbq() and exits.

A STREAMS module or driver that is not multiprocessor-aware (lacks D_MP in its pfxdevflags) uses one set of functions for flow control (see the canput(D3) and bcanputnext(D3) reference pages), while one that is multiprocessor-aware uses a different set (see canputnext(D3) and bcanputnext(D3) ).